## Summary

Enables the copilot-evaluate-tests gh-aw workflow to run on fork PRs by
adding `forks: ["*"]` to the `pull_request` trigger and removing the
fork guard from `Checkout-GhAwPr.ps1`.

## Changes

1. **copilot-evaluate-tests.md**: Added `forks: ["*"]` to opt out of
gh-aw auto-injected fork activation guard. Scoped `Checkout-GhAwPr.ps1`
step to `workflow_dispatch` only (redundant for other triggers since
platform handles checkout).

2. **copilot-evaluate-tests.lock.yml**: Recompiled via `gh aw compile` —
fork guard removed from activation `if:` conditions.

3. **Checkout-GhAwPr.ps1**: Removed the `isCrossRepository` fork guard.
Updated header docs and restore comments to accurately describe behavior
for all trigger×fork combinations (including corrected step ordering).

4. **gh-aw-workflows.instructions.md**: Updated all stale references to
the removed fork guard. Documented `forks: ["*"]` opt-in, clarified
residual risk model for fork PRs, and updated troubleshooting table.

## Security Model

Fork PRs are safe because:
- Agent runs in **sandboxed container** with all credentials scrubbed
- Output limited to **1 comment** via `safe-outputs: add-comment: max:
1`
- Agent **prompt comes from base branch** (`runtime-import`) — forks
cannot alter instructions
- Pre-flight check catches missing `SKILL.md` if fork isn't rebased on
`main`
- No workspace code is executed with `GITHUB_TOKEN` (checkout without
execution)

## Testing

- ✅ `workflow_dispatch` tested against fork PR #34621
- ✅ Lock.yml statically verified — fork guard removed from `if:`
conditions
- ⏳ `pull_request` trigger on fork PRs can only be verified post-merge
(GitHub Actions reads lock.yml from default branch)

---------

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

… is compiled (#34717)

## Description

Adds regression tests for #34713 verifying the XAML source generator
correctly handles bindings with `Converter={StaticResource ...}` inside
`x:DataType` scopes.

Closes #34713

## Investigation

After thorough investigation of the source generator pipeline
(`KnownMarkups.cs`, `CompiledBindingMarkup.cs`, `NodeSGExtensions.cs`):

### When converter IS in page resources (compile-time resolution ✅)

`GetResourceNode()` walks the XAML tree, finds the converter resource,
and `ProvideValueForStaticResourceExtension` returns the variable
directly — **no runtime `ProvideValue` call**. The converter is
referenced at compile time.

### When converter is NOT in page resources (runtime resolution ✅)

`GetResourceNode()` returns null → falls through to `IsValueProvider` →
generates `StaticResourceExtension.ProvideValue(serviceProvider)`. The
`SimpleValueTargetProvider` provides the full parent chain, and
`TryGetApplicationLevelResource` checks `Application.Current.Resources`.
The binding IS still compiled into a `TypedBinding` — only the converter
resolution is deferred.

### Verified on both `main` and `net11.0`

All tests pass on both branches.

## Tests added

| Test | What it verifies |
|------|-----------------|
| `SourceGenResolvesConverterAtCompileTime_ImplicitResources` |
Converter in implicit `<Resources>` → compile-time resolution, no
`ProvideValue` |
| `SourceGenResolvesConverterAtCompileTime_ExplicitResourceDictionary` |
Converter in explicit `<ResourceDictionary>` → compile-time resolution,
no `ProvideValue` |
| `SourceGenCompilesBindingWithConverterToTypedBinding` | Converter NOT
in page resources → still compiled to `TypedBinding`, no raw `Binding`
fallback |
| `BindingWithConverterFromAppResourcesWorksCorrectly` × 3 | Runtime
behavior correct for all inflators (Runtime, XamlC, SourceGen) |

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

<!-- Please let the below note in for people that find this PR -->
> [!NOTE]
> Are you waiting for the changes in this PR to be merged?
> It would be very helpful if you could [test the resulting
artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from
this PR and let us know in a comment if this change resolves your issue.
Thank you!

## Description

Adds arcade inter-branch merge workflow and configuration to automate
merging `net11.0` into the `release/11.0.1xx-preview3` branch.

### Files added

| File | Purpose |
|------|---------|
| `github-merge-flow-release-11.jsonc` | Merge flow config — source
`net11.0`, target `release/11.0.1xx-preview3` |
| `.github/workflows/merge-net11-to-release.yml` | GitHub Actions
workflow — triggers on push to net11.0, daily cron, manual dispatch |

### How it works

Uses the shared [dotnet/arcade inter-branch merge
infrastructure](https://github.com/dotnet/arcade/blob/main/.github/workflows/inter-branch-merge-base.yml):
- **Event-driven**: triggers on push to `net11.0`, with daily cron
safety net
- **ResetToTargetPaths**: auto-resets `global.json`, `NuGet.config`,
`eng/Version.Details.xml`, `eng/Versions.props`, `eng/common/*` to
target branch versions
- **QuietComments**: reduces GitHub notification noise
- Skips PRs when only Maestro bot commits exist

### Incrementing for future releases

When cutting a new release (e.g., preview4), update:
1. `github-merge-flow-release-11.jsonc` → change `MergeToBranch` value
2. `.github/workflows/merge-net11-to-release.yml` → update workflow
`name` field

Follows the same pattern as `merge-main-to-net11.yml` /
`github-merge-flow-net11.jsonc`.

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

<!--
!!!!!!! MAIN IS THE ONLY ACTIVE BRANCH. MAKE SURE THIS PR IS TARGETING
MAIN. !!!!!!!
-->



<!-- Enter description of the fix in this section -->

### Issues Fixed

<!-- Please make sure that there is a bug logged for the issue being
fixed. The bug should describe the problem and how to reproduce it. -->

Fixes #33355

### Description of Change

This report has the goal to provide a detailed progress on the solution
of the memory-leak

The test consists doing 100 navigations between 2 pages, as the image
below suggest

<img width="876" height="502" alt="image"
src="https://github.com/user-attachments/assets/e9e80768-dd40-4445-9fc8-90469579236c"
/>


Running the gc-dump on the desired objects this is what I found.

> BaseLine is the dump when the app starts.

| | | | | |
| ------------------------------------ | ------- | ------------ |
-------------- | ------------------------ |
| Object Type | Count | Size (Bytes) | Expected Count | Status |
| **Page2** | **100** | 84,000 | 1 | ❌ **LEAKED** (99 extra) |
| **PageHandler** | **103** | 9,888 | 4 | ❌ **LEAKED** (99 extra) |
| **StackNavigationManager** | **102** | 16,320 | 1 | ❌ **LEAKED** (101
extra) |
| **StackNavigationManager.Callbacks** | **102** | 5,712 | 1 | ❌
**LEAKED** (101 extra) |
| **NavigationViewFragment** | **102** | 5,712 | ~2 | ❌ **LEAKED** (100
extra) |

So the first fix was to call `Disconnect` handler, on the
`previousDetail` during the `FlyoutPage.Detail_set`. The PageChanges and
Navigated events will not see this, since this `set` is not considered a
navigation in .Net Maui.

After that we see the following data

| | | | | |
| ------------------------------------ | ------- | ------------ |
---------------------- | ------------ |
| Object Type | Count | Size (Bytes) | vs Baseline | Status |
| **Page2** | **100** | 84,000 | Same | ❌ **LEAKED** |
| **PageHandler** | **103** | 9,888 | Same | ❌ **LEAKED** |
| **StackNavigationManager** | **102** | 16,320 | Same | ❌ **LEAKED** |
| **StackNavigationManager.Callbacks** | **1** | 56 | ✅ **FIXED!** (was
102) | ✅ **Good!** |
| **NavigationViewFragment** | **102** | 5,712 | Same | ❌ **LEAKED** |

So, calling the Disconnect handler will fix the leak at
`StackNavigationManager.Callbacks`. Next step was to investigate the
`StackNavigationManager` and see what's holding it.

On `StackNavigationManager` I see lot of object that should be cleaned
up in order to release other references from it. After cleaning it up
the result is

|   |   |   |   |   |
|---|---|---|---|---|
|Object Type|Count|Size (Bytes)|vs Baseline|Status|
|**Page2**|**1**|840|✅ **FIXED!** (was 100)|✅ **Perfect!**|
|**PageHandler**|**4**|384|✅ **FIXED!** (was 103)|✅ **Perfect!**|
|**StackNavigationManager**|**102**|16,320|❌ Still leaking (was 102)|❌
**Unchanged**|
|**StackNavigationManager.Callbacks**|**1**|56|✅ Fixed (was 102)|✅
**Good!**|
|**NavigationViewFragment**|**102**|5,712|❌ Still leaking (was 102)|❌
**Unchanged**|

So something is still holding the `StackNavigationManager` and
`NavigationViewFragment` so I changed the approach and found that
`NavigationViewFragment` is holding everything and after fixing that,
cleaning it up on `Destroy` method. here's the result

|   |   |   |   |   |
|---|---|---|---|---|
|Object Type|Count|Size (Bytes)|vs Previous|Status|
|**Page2**|**1**|840|✅ Same|✅ **Perfect!**|
|**PageHandler**|**4**|384|✅ Same|✅ **Perfect!**|
|**StackNavigationManager**|**1**|160|🎉 **FIXED!** (was 102)|🎉
**FIXED!**|
|**StackNavigationManager.Callbacks**|**1**|56|✅ Same|✅ **Perfect!**|
|**NavigationViewFragment**|**102**|5,712|⚠️ Still present|⚠️
**Remaining**|

With that there's still the leak of `NavigationViewFragment`, looking at
the graph the something on Android side is holding it, there's no root
into managed objects, as far the gcdump can tell. I tried to cleanup the
`FragmentManager`, `NavController` and so on but without success (maybe
I did it wrong).

There's still one instance of page 2, somehow it lives longer, I don't
think it's a leak object because since its value is 1. For reference the
Page2 graph is
```
Page2 (1 instance)
 └── PageHandler
     └── EventHandler<FocusChangeEventArgs>
         └── IOnFocusChangeListenerImplementor (Native Android)
             └── UNDEFINED

```


Looking into www I found that android caches those Fragments, sadly in
our case we don't reuse them. The good part is each object has only 56
bytes, so it shouldn't be a big deal, I believe we can take the
improvements made by this PR and keep an eye on that, maybe that's fixed
when moved to Navigation3 implementation.

<!-- Please let the below note in for people that find this PR -->
> [!NOTE]
> Are you waiting for the changes in this PR to be merged?
> It would be very helpful if you could [test the resulting
artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from
this PR and let us know in a comment if this change resolves your issue.
Thank you!

## Summary

Adds the `maui device list` command specification to the existing CLI
design document (`docs/design/cli.md`). This command provides unified,
cross-platform device enumeration without requiring a project context.

See [PR #33865](#33865) for the full
DevTools spec.

## What is added

### Command: `maui device list [--platform <p>] [--json]`

Lists connected devices, running emulators, and available simulators
across all platforms in a single call.

### Two approaches analysis

The spec analyzes two discovery approaches and recommends the
project-free one:

| | MSBuild (`dotnet run --list-devices`) | Native CLI (`maui device
list`) |
|---|---|---|
| Project required | Yes | **No** |
| Cross-platform | One TFM at a time | All platforms at once |
| Speed | Slower (MSBuild eval) | Fast (<2s) |
| ID compatibility | Source of truth | Same native IDs |

### Scenarios requiring project-free discovery

1. AI agent bootstrapping (no `.csproj` yet)
2. IDE startup (device picker before project loads)
3. Environment validation ("can I see my phone?")
4. CI pipeline setup (check emulator before build)
5. Multi-project solutions (unified view)
6. Cross-platform overview (all devices at once)

### Recommended approach

`maui device list` uses direct native tool invocation (`adb devices`,
`simctl list`, `devicectl list`). Device IDs are compatible with `dotnet
run --device`, making them complementary:

```
maui device list          →  "What devices exist on this machine?"
dotnet run --list-devices →  "What devices can run this project?"
```

### Other changes

- Added references to `ComputeAvailableDevices` MSBuild targets in
[dotnet/android](https://github.com/dotnet/android) and
[dotnet/macios](https://github.com/dotnet/macios)
- Updated AI agent workflow example to include device discovery step
- Fixed AppleDev.Tools reference (xcdevice → devicectl)

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…34727)

## Description

Fixes #34726

The XAML source generator interpolates `x:Key` values directly into
generated C# string literals without escaping special characters. If an
`x:Key` contains a double quote (`"`), backslash (`\`), or control
character, the generated C# is syntactically invalid.

## Changes

- **`SetPropertyHelpers.cs`** — Escape the `x:Key` value via
`CSharpExpressionHelpers.EscapeForString()` before interpolating into
the generated `resources["..."] = ...` assignment.
- **`KnownMarkups.cs`** — Same fix for `DynamicResource` key emission
(`new DynamicResource("...")`).
- **`CSharpExpressionHelpers.cs`** — Changed `EscapeForString` from
`private static` to `internal static` so it can be reused from
`SetPropertyHelpers` and `KnownMarkups`.

## Test

Added `Maui34726.xaml` / `.xaml.cs` XAML unit test with `x:Key` values
containing double quotes and backslashes:
- **SourceGen path**: Verifies the generated code compiles without
diagnostics
- **Runtime/XamlC paths**: Verifies the resources are accessible by
their original (unescaped) key names

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…34576)

> [!NOTE]
> Are you waiting for the changes in this PR to be merged?
> It would be very helpful if you could [test the resulting
artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from
this PR and let us know in a comment if this change resolves your issue.
Thank you!

## Summary

Major improvements to the Essentials AI sample app: new Landmark Detail
page with AI features, semantic search, streaming response handler
improvements, and comprehensive UI polish across all pages for a modern,
edge-to-edge experience on iOS and MacCatalyst.

### New Features

- **Landmark Detail Page** — New intermediate page between browsing and
trip planning with AI-generated travel tips, similar destinations via
semantic search, animated hashtag tags, language picker, full-bleed hero
image with scrolling gradient overlay, and Plan Trip navigation
- **Semantic Search** — Search bar on Landmarks page filters continent
groups using semantic similarity with `Timer`-based debounce (300ms) and
tracks recent searches for contextual AI descriptions
- **ISemanticSearchService abstraction** — Clean interface backed by
`EmbeddingSearchService` (Apple NL embeddings + cosine similarity +
hybrid keyword boost + sentence chunking)
- **StreamingResponseHandler passthrough mode** — Supports streaming
without buffering, with new device tests
(`DeliversMultipleIncrementalUpdates`, `ConcatenatedText`)
- **PromptBasedSchemaClient** — Prompt-based JSON schema middleware for
Phi Silica compatibility

### UI Polish

- **Edge-to-edge layout** — All pages use `SafeAreaEdges="None"` on root
Grid with back buttons wrapped in `SafeAreaEdges="Container"`
- **Scrolling gradient pattern** — Fixed gradient overlay + scrolling
gradient that transitions to solid background
- **Custom search entry** — Replaced `SearchBar` with borderless `Entry`
in rounded `Border` with native border/focus ring removed on
iOS/MacCatalyst
- **Edge-to-edge horizontal scrollers** — Scroll to screen edges, align
with page content padding at rest
- **Removed broken BoxView global style** — Was breaking gradient
overlays
- **Added missing Gray700 color** — Prevented silent navigation crash
- **Background → Background property migration** — Replaced
`BackgroundColor` with `Background` across all pages

### Code Quality

- **IDispatcher injection** instead of
`MainThread.BeginInvokeOnMainThread`
- **Only-once AI initialization** — Guard against re-entry in
`LandmarkDetailViewModel`
- **Null safety** — Fixed CS8602 warnings in DataService search methods
- **Removed debug logging**

### Navigation Flow

`LandmarksPage` (browse + search) → `LandmarkDetailPage` (details + AI
tips) → `TripPlanningPage` (itinerary generation)

### Deleted Files

- `LandmarkDescriptionView`, `LandmarkTripView` — Replaced by new pages
- `LanguagePreferenceService` — Refactored into inline language array

### New Test Coverage

- `StreamingResponseHandlerTests/Passthrough.cs` — Unit tests for
passthrough streaming mode
- `ChatClientStreamingTestsBase` — Updated device tests for streaming
scenarios

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Reset patterns:
- global.json
- NuGet.config
- eng/Version.Details.xml
- eng/Versions.props
- eng/common/*